One pass security

ABSTRACT

A system and method for secure network communication. In various embodiments of the present invention, data needed for authentication an encryption is included in each communication pass between network devices, so that when a network connection is broken, a secure connection can be reestablished with the next pass. A client authentication service on the client receives a server request and searches for a current client-side session key. If one is not present, the client authentication service generates and encrypts an initial session key, acquires credentials, adds the credentials to the server request, and encrypts the server request with the initial session key. The encrypted server request and the encrypted session key are sent to the server, where a server authentication service decrypts the initial session key, decrypts the server request with the initial session key, and authenticates the credentials before allowing the server request to be acted upon. Where a current client-side session key is detected, the client authentication service acquires the current client-side session key, generates a next step session key, adds the next step session key to the server request, and encrypts the server request with the current client-side session key. The encrypted server request is sent to the server where the server authentication service decrypts the server request with a current server-side session key allowing the server request to be acted upon.

FIELD OF THE INVENTION

[0001] This invention relates generally to securing networkcommunication. More specifically, this invention is directed to one-passauthentication and encryption enabling secure network communication.

BACKGROUND OF THE INVENTION

[0002] With the advent of the Internet, electronic business andfinancial transactions have flourished. Virtual private networks nowenable people to conduct business from anywhere in the world, at leastanywhere an Internet connection is available. With cellular andsatellite communication technology, Internet connections are availablevirtually everywhere. Network communication protocols, such as S-HTTP(Secure Hypertext Transport Protocol) and SSL (Secure Socket Layer),have been developed to enable secure communication links between twonetwork devices. These technologies provide security in twoforms—authentication and encryption. Authentication is important toverify that each device is who it claims to be. Encryption allows thedevices to exchange data rendering that data useless to a third party.The security provides confidence in transmitting private financial,business, and personal data over a computer network.

[0003] In addition to desktop computers, workstations, and servers,modern computing environments often include lightweight handheldcomputing devices that fit into a pocket, purse, or briefcase. To enabletrue mobility for these devices, wireless network communication isrequired. Wireless network interface cards enable network communicationwithin a particular geographic area such as an office complex. Themobile device must remain within range of a server to communicate.Cellular modems and Internet ready cellular telephones enable networkcommunication between devices located most anywhere.

[0004] Existing secure network communication protocols such as SSLrequire a series of communications between two devices to establish asecure communication link between the devices. These communications areoften referred to as a “handshake.” A handshake allows the networkdevices to authenticate one another while exchanging data needed toencrypt future communications. FIG. 1 illustrates a typical handshakebetween a cellular enabled PDA (Personal Digital Assistant) 10 and aserver 12. PDA 10 initiates the handshake communicating data to server12. Server 12 responds sending data to PDA 10. Each communication can bereferred to as a “pass.” Existing protocols require several passes toestablish a secure connection. For example, one version of an SSLhandshake requires the following steps:

[0005] PDA 10 initiates communication requesting a digital certificatefrom server 12. A digital certificate includes a public key used toencrypt a reply as well as electronic data used to authenticate server12.

[0006] Server 12 returns its certificate and requests a digitalcertificate from PDA 10.

[0007] With the server's certificate, PDA 10 authenticates server 12 andreturns its own certificate. With the PDA's certificate, server 12authenticates PDA 10.

[0008] PDA 10 then generates a symmetric encryption key. Using thepublic key from the server's certificate, PDA 10 encrypts the symmetricencryption key and then sends it to server 12. Using its own privatekey, server 12 decrypts the symmetric encryption key.

[0009] The handshake is complete. PDA 10 and server 12 have beenauthenticated. Future communications between PDA 10 and server 12 areencrypted and decrypted using the symmetric encryption key. For example,PDA 10 can generate a request for server (server request) to return datarelating to a bank account for instance. PDA 10 encrypts the serverrequest with the symmetric encryption key and sends it to server 12.Server 12 decrypts the server requests and generates a response to theserver request (client response). Server 12 then encrypts the clientresponse with the symmetric encryption key and returns it to PDA 12which decrypts and displays the client response. Whenever the networkconnection between PDA 10 and server 12 is broken, the handshake must berepeated in order to authenticate the devices. When communicating over acellular connection, each pass of a handshake requires approximatelyfifteen seconds. Consequently, a handshake typically requires anywherefrom forty-five to seventy seconds, before a secure connection can beestablished or reestablished.

[0010] Wireless network connections can be unreliable. They are oftenbroken requiring a secure connection to be frequently reestablished. Theresulting delay of forty-five to seventy seconds required for eachhandshake renders secure cellular network communication annoying if notinefficient or unworkable. What is needed is a more efficient method forestablishing and secure network communication that eliminates the needfor a handshake as described above each time the connection is broken.

SUMMARY OF THE INVENTION

[0011] The present invention is directed to authentication andencryption for secure network communication. In various embodiments ofthe present invention, data needed for authentication an encryption isincluded in each communication pass between network devices, so thatwhen a network connection is broken, a secure connection can bereestablished with the next pass. A client authentication service on theclient receives a server request and searches for a current client-sidesession key. If one is not present, the client authentication servicegenerates and encrypts an initial session key, acquires credentials,adds the credentials to the server request, and encrypts the serverrequest with the initial session key. The encrypted server request andthe encrypted session key are sent to the server, where a serverauthentication service decrypts the initial session key, decrypts theserver request with the initial session key, and authenticates thecredentials before allowing the server request to be acted upon. Where acurrent client-side session key is detected, the client authenticationservice acquires the current client-side session key, generates a nextstep session key, adds the next step session key to the server request,and encrypts the server request with the current client-side sessionkey. The encrypted server request is sent to the server where the serverauthentication service decrypts the server request with a currentserver-side session key allowing the server request to be acted upon.

DESCRIPTION OF THE DRAWINGS

[0012]FIG. 1 is a schematic representation of a mobile computingenvironment illustrating a multi-pass handshake.

[0013]FIG. 2 is a schematic representation of a mobile computingenvironment in which various embodiment of the present invention may beincorporated.

[0014]FIG. 3 is schematic representation of the components of the clientand server devices of FIG. 2 according to one embodiment of the presentinvention.

[0015]FIG. 4 is a schematic representation of the client authenticationservice and client database of FIG. 3.

[0016]FIG. 5 is a schematic representation of the server authenticationservice and server database of FIG. 3.

[0017]FIGS. 6, 7, 8, 9A, and 9B are interrelated flow diagramsillustrating steps followed during an authentication process accordingto one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0018] INTRODUCTION: Traditional security protocols, such as SSL andS-HTTP, require a handshake to establish a secure network connection.For the connection to remain secure, the connection cannot be broken.When broken, the handshake must be repeated to reestablish a secureconnection. In a wireless network, a handshake is a relatively slowprocess. Establishing and then continually reestablishing secureconnection on a wireless network renders the network communicationinefficient if not, in some cases, unworkable.

[0019] It is expected that various embodiments of the present inventionwill enable users to establish and reestablish a secure networkcommunication session with a single pass. Network security isestablished with each application level request that a client makes on aserver and with each application level response that the server returnsto the client. Consequently, as may often be the case, the networkconnection between the client and the server can be broken between eachserver request, client response, and subsequent server request withoutnegatively affecting the communication speed between the client and theserver.

[0020] COMPONENTS: FIG. 2 illustrates a computing environment 16 inwhich various embodiments of the present invention may be incorporated.Embodiments of the present invention, however, may be incorporated inany environment in which it is desirable or necessary to establishsecure network communication. Environment 16 includes server device 18,client devices 20, and link 22, interconnecting client device 18 withclient devices 22. Server device 18 represent generally any computingdevice capable of serving electronic data over link 22. Client devices20 represent generally any computing device capable of communicatingwith server device 18 over link 22. Link 22 represents generally anycable, wireless, or remote connection via a telecommunication link, aninfrared link, a radio frequency link, cellular link, or any otherconnector or system that provides electronic communication between thedevices. Link 22 may represent, in part, an intranet, the Internet, or acombination of both.

[0021]FIG. 3 illustrates the components of server device 18 and a singleclient device 20 used to establish a secure network communication linkbetween the devices. Client device 20 includes client 24, clientapplication 26, network interface 28, client authentication service 30,and client database 32. Client 24 represents any programming capable ofgenerating and sending a server request. A server request is electronicdata formed to instruct a server to perform a particular task. When thattask involves instructing the server to return electronic data, thereturn of that data can be referred to as a client response. However, aserver request may, in some cases, only instruct a server to perform aparticular task without returning electronic data to the client. Clientapplication 26 represents any programming capable of providing client 24with electronic data used to generate the server request. Client 24 andclient application 26 may, in the case of a web browser, be incorporatedin a single application. Network interface 28 represents any combinationof hardware and/or programming capable of transmitting and receivingelectronic data over link 22. Network interface 28 may be a standardnetwork interface card, a wireless network interface card, a wireless orcellular modem, or an Internet ready Cellular telephone. Clientauthentication service 30 represents programming capable of addingelectronic information to and encrypting a server request as well asdecrypting a client response. Client database 32 represents any readableand writeable memory used to hold electronic data used by clientauthentication service 30.

[0022] Server device 18 includes server 34, server application 36,network interface 38, server authentication service 40, and serverdatabase 42. Server 34 represents generally any programming capable ofreceiving and acting on a server request as well as generating a clientresponse. Server application 36 represents programming used by server 34to act on a server request and to generate a client response. Forexample, server application 34 may be a program interface enablingserver 32 to retrieve and manipulate information in a database locatedon server device 18 or elsewhere. Network interface 38 like networkinterface 28 represents any combination of hardware and/or programmingcapable of transmitting and receiving electronic data over link 22.Server authentication service 40 represents generally any programmingcapable of decrypting a server request as well as adding information toand encrypting a client response. Server database 42 represents anyreadable and writeable memory used to hold electronic data used byserver authentication service 40.

[0023] As illustrated in FIG. 4, client authentication service 30includes client encryption module 44, request builder 46, clientsequence module 48, client time module 50, and client integrity module52. Client encryption module 44 represents any programming capable ofgenerating symmetric encryption keys, encrypting server requests, anddecrypting client responses. Request builder 46 represents anyprogramming capable of adding electronic data to a server request,encrypted or not, to be sent by client 24 to server 34. Client sequencemodule 48 represents programming capable of generating and updating asession counter to be added to a server request by request builder 46.The term session represents a period of communication between clientdevice 20 and server device 18 used to perform a particular task ortasks. A session does not require a constant network connection. Anincrementally increased session counter is added to each subsequentserver request during the session to ensure that a single server requestis not acted upon twice by server device 18. For example, the firstsession counter for a session may have a value of zero, the second—avalue of one, and so on. Client time module 50 represents anyprogramming capable of generating a time stamp for request builder 46 toadd to a server request as well as validating a time stamp obtained froma client response. In some instances it may be desirable to break asecure communication link between server and client devices 18 and 20where time between server requests or client responses exceeds aspecified limit. Time stamps enable tracking of the time elapsed betweenserver requests and/or server responses.

[0024] Client integrity module 52 represents programming capable ofgenerating integrity data such as a checksum for request builder 46 toadd to a server request as well as verifying the integrity of a clientresponse. When communicating through a secure network link, it can beimportant to verify that the data making up a server request or a clientresponse has not been intercepted and altered since the request orresponse was sent. A checksum is a numerical value calculated, at leastin part, by the number of bits that comprise an electronic message suchas a server request or client response. Upon receipt of the electronicmessage, if the number of bits does not match the checksum, the receiverof the message, in this case server device 18, can assume that themessage contains errors or has been tampered with.

[0025] Still referring to FIG. 4, client database 32 contains usercredentials 54, server credentials 56, and client temporary data 58.User credentials 54 represent electronic data identifying and unique toa particular user of client device 20 or unique to client device 20itself. It is expected that user credentials will be a username andpassword pair. Server credentials 56 represent electronic data used toencrypt data that can then only be decrypted by server device 18. It isexpected that server credentials will include an asymmetric publicencryption key, referred to herein as a server public key. Clienttemporary data 58 includes the most recently generated session counter,a time stamp obtained from the most recent client response, andelectronic data used by client encryption module 44 to encrypt serverrequests and to decrypt client responses. It is expected that thiselectronic data will include a symmetric encryption key, referred toherein as a current client-side session key, that is periodicallyupdated during a session.

[0026] Referring now to FIG. 5, server authentication service 40includes server encryption module 60, response builder 62, credentialmodule 64, server sequence module 66, server time module 68 and serverintegrity module 70. Server encryption module 60 represents anyprogramming capable of generating symmetric encryption keys, encryptingclient responses and decrypting server requests. Response builder 62represents any programming capable of adding electronic data to a clientresponse, encrypted or not, to be sent by server 34 to client 24.Credential module 64 represents any programming capable ofauthenticating credentials acquired from a decrypted server request aswell as identifying data in server database 42 associated withcredentials obtained from a server request.

[0027] Server sequence module 66 represents programming capable ofstoring a session counter obtained from a server request and comparingthat session counter with the session counter received and storedfollowing a previous server request. Server sequence module 66 can thencompare the stored session counter with a new session counter obtainedfrom the subsequent server request. If the new session counter does notexceed the stored session counter, the subsequent server request is tobe ignored.

[0028] Server time module 68 represents programming capable ofgenerating a time stamp for response builder 62 to add to a clientresponse as well as validating a time stamp obtained from a serverrequest. Server integrity module 70 represents programming capable ofgenerating integrity data such as a checksum for response builder 62 toadd to a client response as well verifying the integrity of a serverrequest.

[0029] Still referring to FIG. 5, server database 42 includes usercredentials 72, server credentials 74, and device record 76. Usercredentials 72 contain electronic data, typically in the form ofverified user name and password pairs used by credential module 64 toauthenticate credentials obtained from a server request. Servercredentials 74 contain data used by server encryption module 60 todecrypt data used to encrypt a server request. It is expected that thisdata will include an asymmetric private encryption key, referred toherein as a server private key. Device record 76 represents electronicdata used by server encryption module 60, server sequence module 66, andserver time module 68 and used to establish secure network communicationwith client device 20. Server database 42 may include other devicerecords to store data for securely communicating with devices other thenclient device 20. It is expected that this electronic data will includea session key that is periodically changed during a given session aswell as a session counter and time stamp for the most recent serverrequest.

[0030] The block diagrams of FIGS. 2-5 show the architecture andfunctionality of one implementation of the present invention. Ifembodied in software, each block may represent a module, segment, orportion of code that comprises one or more executable instructions toimplement the specified logical function(s). If embodied in hardware,each block may represent a circuit or a number of interconnectedcircuits to implement the specified logical function(s).

[0031] Also, the present invention can be embodied in anycomputer-readable medium for use by or in connection with an instructionexecution system such as a computer/processor based system or othersystem that can fetch or obtain the logic from the computer-readablemedium and execute the instructions contained therein. A“computer-readable medium” can be any medium that can contain, store, ormaintain electronic instructions for use by or in connection with theinstruction execution system. The computer readable medium can compriseany one of many physical media such as, for example, electronic,magnetic, optical, electromagnetic, infrared, or semiconductor media.More specific examples of a suitable computer-readable medium wouldinclude, but are not limited to, a portable magnetic computer diskettesuch as floppy diskettes or hard drives, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory, or aportable compact disc.

[0032] OPERATION: The flow diagrams of FIGS. 6, 7, 8, 9A and 9Billustrate steps taken to authenticate network communication accordingto one embodiment of the present invention. The single pass securitymodel according to the present invention can be broken into threeinterrelated branches. The first branch, typically used once, involvesthe client obtaining the server's public encryption key and establishinga device record. The second branch involves establishing a securecommunication session between the client and the server while the thirdbranch involves continuing the secure communication session establishedbetween the client and the server. FIG. 6 illustrates a set of initialsteps taken interrelating the three branches. FIG. 7 illustrates thefirst branch in which steps taken to initialize a client device 20 forsecure network communication. FIG. 8 Illustrates the second branch inwhich steps taken to start a secure communication session, while FIGS.9A and 9B illustrates the third branch in which steps taken to continuean existing secure communication session.

[0033] Referring first to FIG. 6, client authentication service 30determines whether a server public key is present in client database 32(step 80). If not the process continues with the steps illustrated inFIG. 7 to acquire a server public key and to establish device record 76in server database 42 on server device 20. Device record 76 providesserver authentication service 40 with a location in server database 42to store data relating to client device 20. If a server public key ispresent, client 24 waits for a server request. Upon receipt of a serverrequest (step 82), client authentication service 30 determines if acurrent session key exists in client database 32 (step 84). Throughoutthe remainder of the description, a current session key present inclient database 30 will be referred to as a current client-side sessionkey. If one does not exist, the process continues in FIG. 8. If acurrent client-side session key does exist, the process continues inFIGS. 9A and 9B.

[0034] Referring to FIG. 7, client authentication service 30 directsclient 24 to send data to server 34 requesting a server public key (step86). Server 34 receives the request, retrieves the server public keyfrom server database 42 and returns the public key to client 24 (step88). Client authentication service 30 stores the server public key inclient database 32 (step 90) and then directs client 24 to generate andsend a server request to establish a device record and obtain, ifdesired, to return security information. Before sending, clientauthentication service 40 adds user credentials to the server request,generates and adds a session key to the server request, and encrypts theserver request with the server public key (step 92). The requestedsecurity information may include data such as asymmetric public andprivate encryption keys generated for client device 20. Clientauthentication service 30 stores the session key in client database 32to be used to decrypt a client response to the server request.

[0035] Server 34 receives the request, and server authentication service40 decrypts the server request using the server private key (step 94).Obtaining the credentials from the decrypted server request, serverauthentication service 40 authenticates the credentials finding matchingverified credentials located in server database 42 (step 96). If thecredentials cannot be authenticated, the server request is ignored orserver 34 sends a client response challenging client 24 to provide newcredentials. Server authentication service 40 creates device record 76in server database 42 (step 98). This may be accomplished by generatinga device identifier, that is a code unique to client device 20 andcreating a record in server database 42 accessible using the deviceidentifier. Alternatively, server authentication service 40 may create arecord (device record 76) accessible using the credentials obtained fromthe server request.

[0036] Server authentication service 40 instructs server 34 to generateand send a client response that includes the device identifier and mayinclude data such as an asymmetric public and private key pair generatedfor client device 20 (step 100). Server authentication service 40encrypts the client response with the session key provided in the serverrequest (step 100). Client 24 receives the client response, and clientauthentication service 30 decrypts the client response and stores datafrom the response in client database 32 (step 102). The process thenrepeats in FIG. 6.

[0037] Referring now to FIG. 8, upon receipt of a server request andafter not finding a current client-side session key in client database32 in steps 82 and 84, client authentication service 30 generates aninitial session key, storing the initial session key in client database43 and encrypting the initial session key with the server public key(step 104). Client authentication service 30 creates and adds a sessioncounter to the server request (step 106), also adding the password, atime stamp, and a checksum to the server request (steps 108 and 110).Client authentication service encrypts the server request with theinitial session key (step 112). Client 24 bundles the encrypted initialsession key with the encrypted server request and the device identifier(step 114) and sends the bundle to server 34 (step 116).

[0038] Upon receipt by server 34, server authentication service 40decrypts the initial session key with the server private key, locatesdevice record 76 with the device identifier, and stores the initialsession key in device record 76 for client device 20 in server database42 (step 118). Server authentication service then decrypts the serverrequest with the initial session key (step 120), verifies the integrityof the request with the included checksum (step 122), and stores thetime stamp in device record 76 (step 123). With the user credentialsadded to the server request, server authentication service authenticatesthe user finding matching verified credentials in server database 42(step 124). Where the integrity cannot be verified or the user cannot beauthenticated, the server request may be ignored or the serverauthentication device may instruct server 34 to challenge client 24 toresend the server request and/or provide new credentials.

[0039] Server authentication service 40 stores the session counter indevice record 76 in server database 42 (step 126). Server 34 and serverapplication 36 act on the server request, and if required, generate aclient response (step 128). Server authentication service 40 generates anext step session key, adds it to the client response, and then encryptsthe client response with the initial session key, and saves the nextstep session key in device record 76 to be used as a current server-sidesession key used to decrypt a subsequent server request (step 130).Server 34 sends the client response to client 24 (step 132). Clientauthentication service 30 decrypts the client response with the initialsession key and stores the next step session key in client database 32to be used as a current client-side session key to encrypt a subsequentserver request (step 134). The process then repeats in FIG. 6.

[0040] Referring now to FIGS. 9A and 9B, upon receipt of a serverrequest and after finding a current client-side session key in clientdatabase 32 in steps 82 and 84, client authentication service 30generates a next step session key, storing the key in client database 32and adding it to the server request (step 136). Client authenticationservice 30 updates the session counter adding the updated sessioncounter (step 138), a time stamp, and a checksum to the server request(step 140). Client authentication service 30 encrypts the server requestwith the current client-side session key (step 142). Client 24 bundlesthe encrypted server request with the device identifier (step 144) andsends the bundle to server 34 (step 146). The device identifier, may butneed not be encrypted.

[0041] Server 34 receives the server request and device identifier, andserver authentication service 40 locates device record 76 for clientdevice 20 using the device identifier (step 148). Server authenticationservice 40 retrieves the current server-side session key from devicerecord 76 (step 150), decrypts the server request (step 152), verifiesintegrity of the server request with the checksum (step 154), the timestamp (step 156), and the session counter (step 158). If the serverrequest cannot be decrypted or the checksum or the session countercannot be verified, the server request may be ignored or server 35 maychallenge client 24 to resend the server request. Where the time stampcannot be verified, the process continues in FIG. 8. Serverauthentication service 40 saves the session counter in device record 76for client device 18 replacing the prior session counter (step 160).

[0042] Server 34 and server application 36 act on the server request,and if required generate a client response (step 162). Serverauthentication service 40 generates a new next step session key, adds itto the client response (step 164). Server authentication service 40saves the new next-step session key in device record 76 for clientdevice 20, the new key to be used as a current server-side session keyto decrypt a subsequent server request (step 166). Server authenticationservice 40 then encrypts the client response using the next step sessionkey provided with the server request (step 168), and server 34 sends theclient response to client 24 (step 170). Client authentication service30 decrypts the client response with the next step session key sent withthe server request (step 172) and stores the new next step session keyprovided with the client response in client database 32 to be used as acurrent client-side session key used to encrypt a subsequent serverrequest (step 174). The process then repeats in FIG. 6.

[0043] Although the flow diagrams charts of FIGS. 6, 7, 8, 9A, and 9Bshow a specific order of execution, the order of execution may differfrom that which is depicted. For example, the order of execution of twoor more blocks may be scrambled relative to the order shown. Also, twoor more blocks shown in succession in FIGS. 6, 7, 8, 9A, and 9B may beexecuted concurrently or with partial concurrence. All such variationsare within the scope of the present invention. The present invention hasbeen shown and described with reference to the foregoing exemplaryembodiments. It is to be understood, however, that other forms, details,and embodiments may be made without departing from the spirit and scopeof the invention, which is defined in the following claims.

What is claimed is:
 1. A method for secure network communication at thestart of a session, comprising the acts of: receiving a server request;generating and encrypting a session key; acquiring and addingcredentials to the server request; encrypting the server request withthe session key; sending the encrypted server request and encryptedsession key to a server; decrypting the session key; decrypting theserver request with the session key; authenticating the credentials; andacting on the server request if the credentials are authentic.
 2. Themethod of claim 1, further comprising the acts of: generating achecksum; adding the checksum to the server request before encryptingthe server request; and after decrypting, verifying the checksum priorto acting on the server request.
 3. The method of claim 1, furthercomprising the acts of: generating a session counter; adding the sessioncounter to the server request before encrypting the server request; andafter decrypting the server request, storing the session counter for usein future network communications.
 4. The method of claim 1, wherein theact of acquiring credentials comprises acquiring a username and apassword, adding the password to the server request, and wherein the actof sending also includes sending the username, and wherein the act ofauthenticating the credentials comprises authenticating the username andthe password.
 5. The method of claim 1, wherein the act of acting on theserver request comprises: generating a client response; encrypting theclient response with the session key; and sending the response.
 6. Themethod of claim 5, further comprising the acts of generating a next stepsession key and adding the next step session key to the client responseprior to encrypting; storing the next step session key to be used as acurrent server-side session key to decrypt a subsequent server request;decrypting the client response with the session key; and storing thenext step session key to be used as a current client-side session keyused to encrypt the subsequent server request.
 7. A method securenetwork communication during an existing session, comprising the actsof: receiving a server request; acquiring a current client-side sessionkey; generating and adding a next step session key to the serverrequest; encrypting the server request with the current client-sidesession key; sending the server request; acquiring a current server-sidesession key; decrypting the server request with the current server-sidesession key; and acting on the server request.
 8. The method of claim 7,further comprising the acts of: generating a checksum; adding thechecksum to the server request before encrypting the server request; andafter decrypting, verifying the checksum prior to acting on the serverrequest.
 9. The method of claim 7, further comprising the acts of:updating a session counter; adding the updated session counter to theserver request before encrypting the server request; after decryptingthe server request, comparing the updated session counter with a laststored session counter; and wherein the act of acting on the serverrequest comprises acting on the server request only if the updatedsession counter exceeds the last stored session counter.
 10. The methodof claim 7, further comprising adding a device identifier to the serverrequest before sending, and wherein the act of acquiring the currentserver-side session key comprises utilizing the device identifier toacquire the current server-side session key.
 11. The method of claim 10,further comprising, after decrypting the server request, storing thenext step session key such that it is accessible using the deviceidentifier, the next step session key to act as a current server-sidesession key used to decrypt a subsequent server request.
 12. The methodof claim 7, wherein the act of acting on the server request comprises:generating a client response; generating a new next step session key andadding the new next step session key to the client response; storing thenew next step session key to be used as a current server-side sessionkey to decrypt a subsequent server request; encrypting the clientresponse with the next step session key sent with the server request;sending the client response; decrypting the client response with thenext step session key sent with the server request; and storing the newnext step session key to be used as a current client-side session key toencrypt the subsequent server request.
 13. A method for secure networkcommunication, comprising receiving a server request; detecting thepresence of a current client-side session key; if a current client-sidesession key is not detected, generating and encrypting an initialsession key, acquiring credentials, adding the credentials to the serverrequest, encrypting the server request with the initial session key,sending the encrypted server request and the encrypted session key to aserver, decrypting the initial session key, decrypting the serverrequest with the initial session key, and authenticating thecredentials; if a current client-side session key is detected, acquiringthe current client-side session key, generating a next step session key,adding the next step session key to the server request, and encryptingthe server request with the current client-side session key, sending theencrypted server request, and decrypting the server request with acurrent server-side session key; and acting on the server request. 14.The method of claim 13, further comprising the acts of: generating achecksum; adding the checksum to the server request before encryptingthe server request whether or not a current client-side session key isdetected; and verifying the checksum prior to acting on the serverrequest.
 15. The method of claim 13, further comprising the acts of: ifa current client-side session key is not detected, generating a sessioncounter and adding the session counter to the server request beforeencrypting the server request, and, after decrypting the server request,storing the session counter for use in future network communications;and if a current client-side session key is detected, updating thesession counter, adding the updated session counter to the serverrequest before encrypting the server request, after decrypting theserver request, and comparing the updated session counter with a laststored session counter before acting on the server request.
 16. Themethod of claim 13, wherein the act of acquiring credentials comprisesacquiring a username and a password, and wherein the act ofauthenticating the credentials comprises authenticating the username andthe password.
 17. The method of claim 13, further comprising, where acurrent client-side session key is detected, adding a device identifierto the server request, and wherein the act of acquiring the currentserver-side session key comprises utilizing the device identifier toacquire the current server-side session key.
 18. The method of claim 13,wherein the act of acting on the server request comprises: generating aclient response; where a current client-side session key is detected,generating a next step session key, adding the next step session key tothe response, and encrypting the client response with the initialsession key; where current a client-side session key is not detected,generating a new next step session key, adding the new next step sessionkey to the client response, and encrypting the client response with thenext step session key sent with the server request; storing thegenerated next step session key, new or not, to be used as a currentserver-side session key to decrypt a subsequent server request; andsending the encrypted client response.
 19. The method of claim 18,further comprising the acts of where a current client-side session keyis not detected, decrypting the server response with the initial sessionkey and storing the next step session key to be uses as a currentclient-side session key to encrypt a subsequent server request; andwhere a current client-side session key is detected, decrypting theserver response with the next step session key sent with the sessionrequest and storing the new next step session key to be used as acurrent client-side session key to encrypt a subsequent server request.20. A computer program product for secure network communication at thestart of a session, the product comprising computer useable mediumhaving computer readable instructions thereon for: receiving a serverrequest; generating and encrypting a session key; acquiring and addingcredentials to the server request; encrypting the server request withthe session key; sending the encrypted server request and encryptedsession key to a server; decrypting the session key; decrypting theserver request with the session key; authenticating the credentials; andacting on the server request if the credentials are authentic.
 21. Theproduct of claim 20, further comprising instructions for: generating achecksum; adding the checksum to the server request before encryptingthe server request; and after decrypting, verifying the checksum priorto acting on the server request.
 22. The product of claim 20, furthercomprising instructions for: generating a session counter; adding thesession counter to the server request before encrypting the serverrequest; and after decrypting the server request, storing the sessioncounter for use in future network communications.
 23. The product ofclaim 20, wherein the instructions for acquiring credentials compriseinstructions for acquiring a username and a password and adding thepassword to the server request, and wherein the instructions for sendinginclude instructions for sending the username, and wherein theinstructions for authenticating the credentials includes authenticatingthe username and the password.
 24. The product of claim 20, wherein theinstructions for acting on the server request comprise instructions for:generating a client response; encrypting the client response with thesession key; and sending the response.
 25. The product of claim 24,further comprising instructions for: generating a next step session keyand adding the next step session key to the client response prior toencrypting; storing the next step session key to be used as a currentserver-side session key to decrypt a subsequent server request;decrypting the client response with the session key; and storing thenext step session key to be used as a current client-side session keyused to encrypt the subsequent server request.
 26. A computer programproduct for secure network communication during an existing session, theproduct comprising computer useable medium having computer readableinstructions thereon for: receiving a server request; acquiring acurrent client-side session key; generating and adding a next stepsession key to the server request; encrypting the server request withthe current client-side session key; sending the server request;acquiring a current server-side session key; decrypting the serverrequest with the current server-side session key; and acting on theserver request.
 27. The product of claim 26, further comprisinginstructions for: generating a checksum; adding the checksum to theserver request before encrypting the server request; and afterdecrypting, verifying the checksum prior to acting on the serverrequest.
 28. The product of claim 26, further comprising instructionsfor: updating a session counter; adding the updated session counter tothe server request before encrypting the server request; afterdecrypting the server request, comparing the updated session counterwith a last stored session counter; and wherein the act of acting on theserver request comprises acting on the server request only if theupdated session counter exceeds the last stored session counter.
 29. Theproduct of claim 26, further comprising instructions for adding a deviceidentifier to the server request before sending, and wherein the act ofacquiring the current server-side session key comprises utilizing thedevice identifier to acquire the current server-side session key. 30.The product of claim 29, further comprising instructions for, afterdecrypting the server request, storing the next step session key suchthat it is accessible using the device identifier, the next step sessionkey to act as a current server-side session key used to decrypt asubsequent server request.
 31. The product of claim 26, wherein theinstructions for acting on the server request comprise instructions for:generating a client response; generating a new next step session key andadding the new next step session key to the client response; storing thenew next step session key to be used as a current server-side sessionkey to decrypt a subsequent server request; encrypting the clientresponse with the next step session key sent with the server request;sending the client response; decrypting the client response with thenext step session key sent with the server request; and storing the newnext step session key to be used as a current client-side session key toencrypt the subsequent server request.
 32. A computer program productfor secure network communication, the product comprising computeruseable medium having computer readable instructions thereon for:receiving a server request; detecting the presence of a currentclient-side session key; if current client-side session key is notdetected, generating and encrypting an initial session key, acquiringcredentials, adding the credentials to the server request, encryptingthe server request with the initial session key, sending the encryptedserver request and the encrypted session key to a server, decrypting theinitial session key, decrypting the server request with the initialsession key, and authenticating the credentials; if a currentclient-side session key is detected, acquiring the current client-sidesession key, generating a next step session key, adding the next stepsession key to the server request, and encrypting the server requestwith the current client-side session key, sending the encrypted serverrequest, and decrypting the server request with a current server-sidesession key; and acting on the server request.
 33. The product of claim32, further comprising instructions for: generating a checksum; addingthe checksum to the server request before encrypting the server requestwhether or not a current client-side session key is detected; andverifying the checksum prior to acting on the server request.
 34. Theproduct of claim 32, further comprising instructions for: if a currentclient-side session key is not detected, generating a session counterand adding the session counter to the server request before encryptingthe server request, and, after decrypting the server request, storingthe session counter for use in future network communications; and if acurrent client-side session key is detected, updating the sessioncounter, adding the updated session counter to the server request beforeencrypting the server request, after decrypting the server request, andcomparing the updated session counter with a last stored session counterbefore acting on the server request.
 35. The product of claim 32,wherein the instructions for acquiring credentials comprise instructionsfor acquiring a username and a password, and wherein the instructionsfor authenticating the credentials comprise instructions forauthenticating the username and the password.
 36. The product of claim32, further comprising, where a current client-side session key isdetected, instructions for adding a device identifier to the serverrequest, and wherein the instructions for acquiring the currentserver-side session key comprise instructions for utilizing the deviceidentifier to acquire the current server-side session key.
 37. Theproduct of claim 32, wherein the instructions for acting on the serverrequest comprise instructions for: generating a client response; where acurrent client-side session key is detected, generating a next stepsession key, adding the next step session key to the response, andencrypting the client response with the initial session key; wherecurrent a client-side session key is not detected, generating a new nextstep session key, adding the new next step session key to the clientresponse, and encrypting the client response with the next step sessionkey sent with the server request; storing the generated next stepsession key, new or not, to be used as a current server-side session keyto decrypt a subsequent server request; and sending the encrypted clientresponse.
 38. The product of claim 37, further comprising instructionsfor: where a current client-side session key is not detected, decryptingthe server response with the initial session key and storing the nextstep session key to be uses as a current client-side session key toencrypt a subsequent server request; and where a current client-sidesession key is detected, decrypting the server response with the nextstep session key sent with the server request and storing the new nextstep session key to be used as a current client-side session key toencrypt a subsequent server request.
 39. A system for secure networkcommunication, comprising: a request builder operable to act on a serverrequest; a client encryption module operable to generate session keys,encrypt the server request with a generated or an acquired session key,and to decrypt a client response with a generated or an acquired sessionkey; a response builder operable to act on the client response generatedin response to the server request; and a server encryption moduleoperable to generate session keys, encrypt the client response with agenerated or an acquired session key, and to decrypt the server requestwith an acquired session key.
 40. The system of claim 39, wherein: therequest builder is further operable add credentials to the serverrequest and to add a next step session key to the server request; theclient encryption module is further operable to detect whether a currentclient-side session key is available; if a current client-side sessionkey is not available, to generate an initial session key, to encrypt theserver request, including the credentials, with the initial session key,and to encrypt the initial session key with a server public key; If acurrent client-side session key is available, to generate a next stepsession key and to encrypt the server request, including the next stepsession key, with the current client side session key and to store thenext step session key in the client database as a current client-sidesession key to be used to decrypt a subsequent client response; theserver encryption module being further operable to: decrypt the initialsession key with a server private key; decrypt the server request withthe initial session key or a current server-side session key; andencrypt the client response with the next step session key.
 41. Thesystem of claim 40, wherein the client authentications service furtherincludes a client integrity module operable to create a checksum for theserver request, the request builder being further operable to add thechecksum to the server request, and wherein the server authenticationservice further comprises a server integrity module operable to validatethe integrity of the server request using the checksum.
 42. The systemof claim 40, wherein the client authentication service further includesa client sequence module operable to create and update a sessioncounter, the request builder being further operable to add the sessioncounter to the server request, and wherein the server authenticationservice further comprises a server sequence module operable to validatethe session counter.
 43. The system of claim 40, wherein the serverencryption module is further operable to: generate and store a new nextstep session key to be used as a current server-side session key todecrypt a subsequent server request; and to encrypt a client responseusing the next step session key or the initial session key provided withthe server request; wherein the response builder is further operable toadd the new next step session key to the client response.
 44. The systemof claim 43, wherein the server authentication service further includesa server integrity module operable to create a checksum for the clientresponse, the response builder being further operable to add thechecksum to the client response, and wherein the client authenticationservice further comprises a client integrity module operable to validatethe integrity of the client response using the checksum.
 45. A systemfor secure network communication, comprising: a means for adding asession key and a session counter to a server request; a means adding asession key to a client response adding a session key; a means forgenerating session keys; a means for encrypting a session key with aserver public key; a means for encrypting the server request with agenerated or an acquired session key, and decrypting the client responsewith a generated or an acquired session key; a means for encrypting theclient response with a generated or an acquired session key and todecrypting the server request with an acquired session key; a means forpassing encrypted server requests, encrypted client responses, andencrypted session keys between a client and a server; and a means forvalidating the session counter.